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Abstract 



The digital network (13) provides a link between the computer of a customer (2) his home bank (6), a 
supplier (8) and the suppliers bank (1 ). Built into the customer and supplier systems are security modules 
(3). A checking element server (12) is located between the customers banking system and that of the 
supplier's bank, to guarantee payment. The server has specific test elements that relate to the banking 
systems stored in memory and they are accessed to control the communication. 
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Prufungsantrag gem. § 44 PatG ist gestellt 

(g) Verfahren und Anordnung zur Integration von Kunden/Handiern innerhalb bestehenderZahlungsstrukturen 
bei der Abwicklung des Zahlungsverkehrs uber Netze 

@ Die Erflndung betrHft ain Verfahren und eina Anordnung 
zur Intdgration von Kundan/Handlern Innerhalb bastehander 
Zahlungsstrukturen bei der Abwicklung des Zahlungsver- 
kehrs uber Netze. 

Aufgaba der Erfindung ist es, ein preiswertes und unkompli- 
ziertes Verfahren zur Abwicklung von Zahlungen auf digita- 
len Netzen durch EInbeziehung von vorhandenen Zahlungs- 
strukturen zu entwickeln. 

Nach Rgur (1) wird die Aufgabe dadurch getdst dafi mlt 

einem Sicherhaitsmodul (3), aus einem Homebankingsen/er 

Kundenbank (4), einer Kundenbank EOV (5) dar Kundenbank 

(6), dam Handlerrechner (7) des Handlers (8) mit dam 

Sicherheitsmodui (3), optional aus einem Homebankingser- 
^ ver Handlerbank (9), der Handlerbank EDV (10) der Handler- 
^ bank und einem Prufelemantepoolserver (12), wobei dleser 

von dem Handlerrechner (7), der Kundenbank EDV (5) und 
lA der Handlerbank EDV (10) uber ein Netz (13) errelchbar ist 
9 und die Zahlungsanweisungen von dem Handlerrechner (7) 
O uber den Kundanrechner (1) an den Homebankingserver 
CO Kundenbank (4) in die Kundenbank EOV (5) zur Handlerbank 
N EDV (10) geleitet werden, wobei der Handier (8) die 
(0 Gultlgkeit der Zahiungsanweiaung mit Hilfe von Oaten aus 
O) dem Prufelemantepoolserver (12) selbar prufen und ohne 

Verzogerung die Waren Oienstleistungen (33) an den Kun- 

den (2) ausliefern kann. 

a 
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Beschrei 



Die Erfindung betrifft ein v3HKren und eine Anord- 
nung zur Abwicklung von kostengunstigen Zahlungen 
auf digitalen Netzen durch Anbindung an vorhandene 5 
Zahlungsstrukturen. Die Erfindung ist einsetzbar zur 
Abwicklung von Geschaften iiber digitale Netzwerke 
wie dem Internet und anderen Netzwerkea 

Immer haufiger werden Geschafte fiber digitale 
Netzwerke, wie dem Internet oder andere Netze, abge- 10 
wickelt Dabei spielt die Art der Zahlung und die Zah- 
lungsabwicklung eine wichtige Rolle. Waren oder 
Dienstleistungen konnen sehr einfach angeboten wer- 
den, aber die Abwicklung der Zahlung stellt ein groBes 
Problem dar. Bisher wurden verschieden Ansatze zur 15 
Losung des Problems gefunden, wobei jede der Losun- 
gen, sowohl aus einer technischen Komponente, z.B. 
aus einer Verschlusseiungssof t- oder Hardware, als auch 
aus einer ProzeBkomponente besteht 

Eines der bekannten Verfahren zur Abwicklung von 20 
Zahlungen wird 2.B. von VISA und MASTERCARD 
propagiert Dabei handelt es sich um das SET-ProtokoU 
mit dessen Hilfe Kreditkartendaten verschlusselt und 
die verschliisselten Kreditkartendaten vom Kunden an 
den Handler ubertragen werden. Der Handler iibertragt 25 
anschlieBend seinerseits diese Daten an die nachste 
Clearingstelle, wo das eigentliche bekannte Kreditkar- 
tenclearing ausgefuhrt wird. Die Kosten fiir das Verfah- 
ren sind also mit den Kosten der Kreditkartenorganisa- 
tionen belastet Zusatziich ist zu beachten, daB in vielen 30 
Landern keine Kreditkarten (oder die Kreditkarten 
nicht in dem MaBe) genutzt werden. Folglich konnen die 
Nutzer von Kreditkarten in solchen LSndern nicht mit 
diesen Kreditkarten bezahlen. 

Des weiteren sind die Kosten fiir die Handler, die eine 35 
Kreditkartenzahlung akzeptieren, relativ hoch, was den 
Gewinn an den verkauften Gutern oder Dienstleistun- 
gen verringert Es ist weiterhin anzumerken, daB das 
Risiko fiir einen Zahlungsausfall bei der Kreditkarten- 
organisation gegenuber dem Kimden relativ hoch ist 40 
und der Kunde gegenuber dem Handler nicht anonym 
bleibt 

Ein weiteres Verfahren ist das Bezahlen uber digitales 
Geld, ob in Form einer Chipkarte oder in Form von 
ladbaren Ziffernfolgen, wie es bei DIGICASH moglich 45 
ist Die Verfahren benotigen jedoch eine aufwendige 
Abwicklung. Es muB eine emittierende Stelle gefunden 
werden, bei welcher der Kunde sein "echtes Geld" hin- 
terlegt oder per Kreditkarte ''vu-tuelles Geld" kauft Die 
Emission und die ProzeBkosten fur ein solches virtuelles 50 
Geld sind aus nachfolgend aufgefiihrten Griinden rela- 
tiv hoch: 

1. Der Kunde muB sich bei der Bank melden. identi- 
fizieren und einen Geldbetrag anfordem. Dazu 55 
muB die Bank aufwendige Rechenschritte vollzie- 
hen, in denen verschiedene kryptologische Prozes- 

se ablaufen, die relativ viel Rechenleistung benoti- 
gen. 

2. Der Kunde kann nun mit dem von Dim erhalte- eo 
nen digitalen Geld bei einem Handler bezahlen, der 
diese Art der Zahlung akzeptiert, indem er eine 
bestimmte Menge dieser digital signierten Zahlen 
an den Handler ubertragt 

3. Der Handler muB sofort Kontakt mit der Bank 65 
aufnehmen und uberprufen, ob er wirklich giiltiges 
digitales Geld erhalten hat und nicht jemand unbe- 
rechtigt versucht, mit gef alschtem digitalen Geld zu 



bezahlen. ^^^k 

4. Die Bank iib^^Bft, ob schon einmal mit diesem 
digitalen Geld b^hlt wurde. Ist dies nicht der Fall, 
streicht sie das Geld aus der Liste der digital ausge- 
geben Geldbetrage heraus und meldet dem Hand- 
ler, daB er sein Geld demnachst bekommen wird. 

5. Der Handler meldet dem Kunden zuriick: "Alles 
ist in Ordnung, die Ware kann gelief ert werden." 

6. Es muB darauf geachtet werden, daB das digitale 
Geld auch relativ schnell altert Da es uber ein digi- 
tales Signaturverfahren mit Hilfe asynunetrischer 
Algorithmen, wie RSA, geschutzt wird, werden be- 
stimmte Private Key und Public Key verwandt, die 
in endlicher Rechenzeit berechnet werden konnen. 
Deshalb muB das Geld immer wieder aufgefrischt 
werden, bevor ein theoretisches Nachrechnen der 
Private Keys moglich ist Dies erzeugt relativ hohe 
Kosten im ProzeBablauf und in der Verwaltung, so 
daB diese Kosten ebenfalls von den Kunden oder 
von den Handlern gedeckt werden miissen. Gleich- 
zeitig stellt sich als Problem dar, daB die Einnah- 
men aus DIGICASH und Kreditkartengeschaften 
in die bestehende Buchfiihrung des Handlerunter- 
nehmens eingegeben werden miissen. Damit kom- 
men zusatzliche Kosten auf den Handler zu, da er 
eine neue Zahlungsform in seine Buchhaltung inte- 
grieren muB, was bei groBen Untemehmen zu er- 
heblichen Summen f uhrt 

7. Digitales Geld bringt ebenfalls das Problem der 
Geldmengenkontrolle mit sich. Hier wird eine neue 
Zahlungsform, eine Art neues Geld eingefuhrt, was 
nur schwer kontroUiert werden kann. 

AUe anderen Verfahren sind zumeist mit einem der 
beiden Systeme DEBIT oder dem Kreditkartensystem 
verwandt und werden in ahnlicher Form abgewickelt 

Neben den sehr hohen ProzeBkosten, kommt noch 
eine sehr starke Sicherheitsproblematik hinzu. Digitales 
Geld kann naturlich sehr einfach von der Festplatte des 
Besitzers kopiert werden. Bei der Kreditkarten- oder 
bei der Chipkartenlosung ist das Problem ebenfalls 
nicht zur Genuge gelost weil die Rechner der Endkun- 
den, von denen die Zahlungsinformationen an den 
Handler oder an die Bank iibertragen werden, unsicher 
sind. Durch den AnschluB an das Internet, ist die Sicher- 
heitsstufe des Rechners identisch mit der Sicherheitsstu- 
fe des gesamten Netzes. Damit kann auf dem Rechner 
des Kunden relativ einfach iiber einen Trojaner oder 
uber einen Computervirus zugcgriffen werden. Dieser 
Virus konnte bspw. die. Datei mit dem DIGICASH ko- 
pieren und auf eine bestimmte Adresse versenden oder 
eine Oberweisung vom Rechner des Kunden ausf iihren. 

Zusammenfassend ist keine der bisher bekannten L6- 
sungen im Ablauf hinreichend unkompliziert und beziig- 
lich der Sicherheit des Systems geniigend auf digitale 
Angriffe vorbereitet 

Aufgabe der Erfindung ist es, ein preiswertes und 
unkompliziertes Verfahren zur Abwicklung von Zah- 
lungen auf digitalen Netzen durch Einbeziehung von 
vorhandenen Zahlungsstrukturen zu entwickeln, wo- 
nach die Kunden und die Handler preiswert Zahlungen 
vomehmen und dabei auf bestehende Infrastrukturen 
zuriickgreifen konnen sollen und die Sicherheit gegen- 
iiber digitalen Angriffen gewahrleistet werden soli. 

ErfindungsgemaB wird die Aufgabe durch die im Pa- 
tentanspruch 1 aufgefuhrten Merkmale geldst 

Weiterbildungen der Erfindung ergeben sich aus den 
Unteranspruchen. 
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Die VorteUe der Erfindung bpighen darin, daB die 
Zahlungsproblematik in digital^^%zen gelost werden 
kann, ohne cine neue Geldart olS^ahrungsart einzu- 
fiihren, jedoch mit wesentlich geringeren Abwicklungs- 
kosten als die bisher bekannten Zahlungsverfahrea Da- 
bei wird auf bestehende Infrastrukturen zugegriffen, die 
bisher nicht geeignet waren, digitale Zahlungsstrdme 
anzunehmen oder digitale Zahlungen abzuwickeln." Die 
Losung erzeugt keinen groBen Datenverkehr auf den 
digitalen Netzen und es bedarf keiner Bestatigungen bei 
dritten Instanzen fur die Echtheit der Zahiung. Die Ano- 
nymitat der ZahJungen kann optional gewahrleistet 
werden. Die ProzeBsicherheit des Systems wird gegen- 
uber bisherigen Debitor-, Kreditorsystemen wesentlich 
erhoht und fur den Kunden flexibler gestaltet Jeder 
Kunde kann sehr einfach ebenfalls zum Handler wer- 
den, ohne das er andere technische Voraussetzungen 
schaffen muB. 
Die Erfindung wird mit 



10 



15 



rechner 7 weiterleit^j^jder Handler 8 die Giiltigkeit 
der ZahlungsanweisP^^it Hilfe von Daten aus dem 
Priifelementepoolserver 12 seiber priifen und ohne Ver- 
zogerung die Waren und Dienstleistungen an den Kun- 
den 2 ausliefem kann. 

Nach Fig. 2 ist die Infrastruktur zwischen dem Kun- 
den 2 bzw. Handler 8, der Kundenbank 6 bzw. Handler- 
bank 11 in der Weise dargestellt, daB der Kundenrech- 
ner 1 bzw. der der Handlerrechner 7 zusatzlich zu Si- 
cherheitsmodul 3 eine Nutzerschnittstelle 14 und eine 
Protokollebene 15 besitzt, wobei eine Verbindung des 
Kundenrechners 1 bzw. des Handle rrechners 7 uber das 
Netz 13 uber den Homebankingserver Kundenbank 4 
bzw. optional uber den Homebankingserver Handier- 
bank 9 an die Kundenbank EDV 5 bzw. Handlerbank 
EDV 10 besteht 

Nach Fig. 3 wird das hardwarebasierende Sicher- 
heitssystem dargestellt, wobei das Sicherheitsmodul 3 
als Hardwaresicherheitsmodul 3a aus einem Sicher- 



Fig. 1 als Integrationssystem zur Abwicklung von ko- 20 heitsprotokoll mit Algorithmen 16, aus einer Schliissel- 



stengiinstigen Zahlungen auf digitalen Netzen, 

Fig. 2 als Infrastruktur zwischen Kunden/Handler 
und Bank, 

Fig. 3 als optionales hardwarebasierendes Sicher- 

heitssystem, 
Fig. 4 als Homebankingserversystem, 
Fig. 5 als Prufelementepoolserversystem, 
Fig. 6 als Verfahrensschritt 1, indem ein gesicherter 

Kanal im Netz aufgebaut wird, 



feldverwaltung 17 dem ein Schlusselfeld Sbk 18 (der 
Subindex B kennzeichnet die einzehie betrachtete Kun- 
denbank innerhalb der Menge aller Banken, der Subin- 
dex K kennzeichnet den einzelnen betrachteten Kunden 
25 innerhalb der Menge aller Kunden) nach der Initiaiisie- 
rung zugeordnet ist, aus einer Signaturfeldverwaltung 
19, und aus einem Eingabesicherheitsmodul 20, das mit 
der Tastatur 21 in Wirkverbindung treten kann, besteht 



In der Fig. 4 ist das Homebankingserversystem Kun- 
Fig. 7 als Verfahrensschritt 2, indem der Handler als 30 den/Handlerbank 4; 9 in der Weise angeordnet, daB es 
Handler registriert wird, aus einem Firewall 22, aus einem Signaturserver 23, aus 

Fig. 8 als modifizierter Verfahrensschritt 2, indem der einem Kommunikationsserver 24, aus einer dynami- 
Handler iiber seine Bank einen gesicherten Kanal nutzt, schen Serverschliisselfeldverwaitung 25 und einem Pro- 
Fig. 9 als Verfahrensschritt 3, indem der Kunde die tokoUserver 26 besteht, wobei der Firewall 22 mit dem 
Ware/Dienstleistung bestellt und einen Oberweisungs- 35 Netz 13 sowie mit einem Kommunikationsserver 24 und 



satz erhait, 

Fig. 10 als Verfahrensschritt 4, indem der Kunde seine 
Bank zur Zahiung anweist, 

Fig. 1 1 als Verfahrensschritt 5, indem der Kunde die 
Zahlungsbestatigung erhalt. 

Fig. 12 als Verfahrensschritt 6, indem der Handler die 
Zahlungsbestatigung erhalt, 

Fig. 13 als Verfahrensschritt 7, indem der Handler die 
Zahlungsbestatigung Clberpriift und bei Echtheit die 



dem Signaturserver 23 verbunden ist und der Kommu- 
nikationsserver 24 mit der Kunden-ZHandlerbank EDV 
4; ID sowie mit der dynamischen Serverschliisselfeldver- 
waitung 25 verbunden ist, indem die Serverschiussel- 
40 feldverwaltung 25 eine Schliisselfeldgenerierung 27 be- 
inhaltet, welche die kunden- und bankspezifischen 
Schlusselfeider Sbk 18 (der Subindex B kennzeichnet 
die einzelne betrachtete Kundenbank innerhalb der 
Menge aller Banden, der Subindex K kennzeichnet den 



Ware/Dienstleistung an den Kunden lief art zur Abwick- 45 einzelnen betrachteten Kunden innerhalb der Menge 



lung von kostengunstigen Zahlungen auf digitalen Net- 
zen, dargestellt 

Nach Fig. 1 besteht das Integrationssystem zur Ab- 
wicklung von kostengunstigen Zahlungen auf digitalen 
Netzen aus dem Kundenrechner 1 des Kunden 2 (einer 50 
von beliebig vielen Kunden) mit einem Sicherheitsmo- 
dul 3, aus einem Homebankingserver Kundenbank 4, 
einer Kundenbank EDV 5 der Kundenbank 6 (eine von 
beliebig vielen Banken), dem Handlerrechner 7 des 
Handlers 8 (einer von beliebig vielen Handlem) mit dem 
Sicherheitsmodul 3, optional aus einem Homebanking- 
server Handlerbank 9, der Handlerbank EDV 10 der 
Handlerbank 11 (einer von beliebig vielen Banken) und 
einem Priifelementepoolserver 12, wobei dieser von 
dem Handlerrechner 7, der Kundenbank EDV 5 und der 
Handlerbank EDV 10 Uber ein Netz 13 erreichbar ist 
und die Zahlungsanweisungen von dem Handlerrechner 
7 liber den Kundenrechner 1 an den Homebankingser- 
ver Kundenbank 4 m die Kundenbank EDV 5 zur Hand- 
lerbank EDV 10 geleitet werden, wobei der Homebank- 
ingserver Kundenbank 10 bei einer erfolgreichen Ak- 
tion die Bestatigung der Ausfiihrung von der Kunden- 
bank EDV 5 uber den Kundenrechner an den Handler- 
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aller Kunden) sowie der ProtokoUserver 26 alle auftre- 
tenden Datenstrome uber den Kommunikationsserver 

24 protokolliert 

Nach Fig, 5 besteht der Priifelementepoolserver 12 
aus dem Firewall 22, aus dem Kommunikationsserver 
24, aus der dynamischen Serverschlusselfeldverwaltung 

25 mit der Schliisselfeldgenerierung 27, welche die 
handlerspezifischen Schlusselfeider Sh 28 (der Subindex 
H kennzeichnet den einzelnen betrachteten Handler in- 
nerhalb der Menge aller Handler) generiert, aus dem 
ProtokoUserver 26, dem Bankenpriifelementepool 29 
und einem Handlerregistrier- und Verwaltungsmodul 
30, indem der Firewall 22 mit dem Netz 13, dem Kom- 
mimikationsserver 24 und dem Bankenpriifelementepo- 
ol 26 Daten austauscht, der Kommunikationsserver 24 
mit der dynamischen Serverschliisselfeldverwaitung 25 
sowie mit dem Handlerregistrier- und Verwaltungsmo- 
dul 30 verbunden ist und der ProtokoUserver 26 alle 
Datenstrome fiber den Kommunikationsserver 24 pro- 
tokolliert 

In Fig. 6 wird der erste Verfahrensschritt zur Abwick- 
lung von kostengunstigen Zahlungen auf digitalen Net- 
zen wie folgt dargestellt Im ersten Verfahrenschritt 
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wird zwischen dem Homeban^Mserver Kundenbank 4 
der Kundenbank 6 und dem ^^Kmentepoolserver 12 
ein gesicherter Kanal uber wBRetz 13 bspw. durch 
Verschliisselung 32 aufgebaut Der Homebankingserver 
Kundenbank 4 sendet sein Prufelement (z. B. den Public 
Key der Bank) Pb 31 (der Subindex B steht fur die be- 
trachtete Bank aus der Menge aller Banken) an den 
Priifelementepoolserver 12 uber den gesicherten Kanal. 
Somit sind ira Pnifelementepool 29 die Priifelemente Pb 
31 (der Subindex B steht fur die betrachtete Bank aus 
der Menge aller Banken) von alien an das System ange- 
schlossenen Banken verfiigbar. 

Nach Fig. 7 laBt sich im zweiten Verfahrenschritt der 
Handler 8 beim Priifelementpoolserver 12 als Handler 
registrieren und erhalt so eine Berechtigung zum Zu- 
griff auf den Prafelementpoolserver 12, in dem limi das 
handlerspezifische Schlusselfeld Sh 28 auf einem siche- 
ren Kanal bspw. mittels Verschliisselung 32 uber das 
Netz 13 zugefiihrt wird Mit Hilfe des Schiusselfeldes Sh 
ist der Handler 8 in der Lage, einen authentisch ver- 
schlusselten Kanal mit dem Prufelementepoolserver 12 
aufzubauen. 

Nach Fig. 8 wird eine modifizierte Variante des zwei- 
ten Verfahrensschrittes beschrieben, indem der Handler 
8 das handlerspezifische Schlusselfeld Sh 28, welches 
ihm den authentischen Zugriff auf den Priifelementepo- 
olserver 12 erlaubt iiber eine Bank beantragt. Dabei 
wird das handlerspezifische Schlusselfeld Sh 28 in einer 
nur fiir den Handler 8 lesbaren Form vom Priifelemen- 
tepoolserver 12 auf einem sicheren Kanal bspw. mittels 
Verschliisselung 32 uber das Netz 13 zum Homebank- 
ingserver Kunden-ZHandlerbank 4; 9 iibertragen und 
auf einem sicheren Kanal bspw. mittels einer erneuten 
Verschliisselung 32 iiber das Netz 13 zum Handlerrech- 
ner 7 des Handlers 8 ubertragea Der Handler 8 spei- 
chert das iiber einen authentischen Kanal von seiner 
Bank erhaltene handlerspezifische Schliisselfeld Sh 28 
in seinem Hardwaresicherheitsmodul 3a ab. 

Nach Fig. 9 nimmt im Verfahrensschritt 3 der Kunde 
2 Kontakt bspw. uber das Netz 13 mit dem Handler 8 
auf, sucht sich eine Ware oder Dienstieistung 33 aus und 
bestellt diese. Als Antwort auf die Bestellung wird in 
einem zwischen dem Handler 8 und dem Kunden 2 ver- 
einbarten sicheren Kanal vom Handler ein Oberwei- 
sungssatz Handler 34 an den Kunden 2 ubertagen. Wo- 
bei der Oberweisungssatz Handler 34 aus Zahlungsin- 
formationen 35. d. h. die Angabe von zahlungsrelevan- 
ten Informationen: Bankleitzahl; Kontonununer; Bank- 
institut; Name; Betrag -I- Wahrung; sonstige Organisa- 
tionsinformationen, und erweiterte Informationen 36 
besteht, in welchem verwaltungs- und produktspezifi- 
sche Anmerkungen stehen konnen. 

Nach Fig. 10 fugt im 4. Verfahrensschritt der Kunde 2 
dem Oberweisungssatz Handler 34 mit Hilfe seines Si- 
cherheitsmoduis 3 den komplettierenden Teil der Ober- 
weisung als Oberweisungssatz Kunde 37 hinzu, so daB 
eine vollstandige Oberweisung entsteht. Diese Ober- 
weisung wird anschlieBend iiber einen sicheren Kanal 
bspw. mittels Verschliisselung 32 mittels des bank- und 
kundenspezifischen Schiusselfeldes Sbk 18 vom Kunden 
2 an den Homebankingserver Kundenbank 4 ubertra- 
gen, auf Vollstandigkeit und Authentizitat uberpruft um 
anschlieBend weiter an die Kundenbank EDV 5 geleitet 
zu werden, wo die Abbuchung genehmigt oder abge- 
lehntwird. 

Ist die Entscheidung fur die Abbuchung erfolgreich 
gefallt worden veranlaBt nach Fig. 11 im 5. Verfahrens- 
schritt die Kundenbank 6 die Oberweisung an die Hand- 



lerbank 11 in den bM|»|bestehenden Zahlungssystemen 
an die Handlerban^H*/ 10. Gleichzeitig geht von der 
Kundenbank EDV^Wne Nachricht an den Homebank- 
ingserver Kundenbank 4, daB die Oberweisung ausge- 
5 fiihrt wird. Nun erzeugt der Homebankingserver Kun- 
denbank 4 einen signierten Bestatigungssatz 38 und 
iibertragt ihn iiber einen sicheren Kanal, bspw. mittels 
Verschliisselung 32 mittels des bank- und kundenspezifi- 
schen Schiusselfeldes Sbfc 18 iiber das Netz 13 an dem 
10 Kunden 2. 

Nach Fig. 12 wird im Verfahrensschritt 6 der Bestati- 
gungssatz 38, welcher aus einer Signatur 39, welche 
bankspezifisch ist, Zahlungsinformationen 35, d. h. Or- 
ganisisationsinformation, Bankidentifikation, Oberwei- 

15 sungszeitpunkt, Datum, Betrag -i- Wahrung, und erwei- 
terten Informationen 36 besteht, vom Kunden 2 iiber 
einen beliebigen vereinbarten Kanal bspw. iiber das 
Netz 13 an den Handler 8 iibertragen. 
Nach Fig. 13 iiberpriift im 7. Verfahrensschritt der 

20 Handler 8 die Signatur 39 des Bestatigungssatzes 38 
indem die Signatur 39 eine Funktion des Bestatigungs- 
satzes 38 und des bankspezifischen Priifelementes Pa 31 
ist, indem der Handler 8 das bankspezifische Priifele- 
ment Pb 31 aus seinem Speicher oder optional authen- 

25 tisch iiber einen sichern Kanal bspw. mittels Verschliis- 
selung 32 mittels des handlerspezifischen Schiusselfel- 
des Sh 28 vom Priifelementepoolserver 12 bezieht und 
die Signatur 39 auf Echtheit uberpruft Ist diese Ober- 
priifung korrekt, veranlaBt der Handler 8 die Oberwei- 

30 sung der Ware- Dienstieistung 33 an den Kunden 2, wo- 
mit das Verfahren zur Abwicklung des Zahlungsver- 
keiirs iiber Netze beendet isL 

Die erfindungsgemaBe Losung ist dadurch charakte- 
risiert, daB einzelne Nutzer im Handelssystem, also der 

35 Kunde 2 und der Handler 3 gewisse infrastrukturelle 
Voraussetzungen erfiillen mussen, um an dem Handels- 
system teilzunehmen. Um die Funktion des Kaufens und 
Verkaufens gegeniiber dem Kunden 2 abzuwickeln, 
wird auf dem Kundenrechner 1 eine Nutzerschnittstelle 

40 14 benotigt Diese kann auf verschiedenste Weise aus- 
gefiihrt sein. Entweder als eigenstandiges Programm 
Oder als Teil eines andem Programmes z.B. eines 
Browsers. Dabei kann die Nutzerschnittstelle 14 gra- 
fisch gestaltet sein, in dem bspw. das Geld durch kleine 

45 Geldsacksymbole dargestellt und die Zahlung durch ei- 
ne Bewegung eines dieser Symbole auf eine "Landefla- 
che" aktiviert wird. Nach dieser Absichtserkiarung zur 
Ausfiihrung eines Zahlungsproz esses wird der eigentli- 
che Zahlungsvorgang gestartet Die vielfaltigen Mog- 

50 lichkeiten, welche der Kunde zum Starten eines Zah- 
lungsprozesses durch eine grafische Schnittstelle hat, 
soUen hier nicht weiter ausgefiihrt werden. 

Neben der Nutzerschnittstelle 14 ist in jedem System 
eine Protokollebene 15 integriert, die die verschiedenen 

55 spater dargestellten Prozesse abwickelt und koordi- 
niert, so daB der Kunde nur die minimalen Aktionen 
vollfQhren muB. 

Das Sicherheitsmodul 3 ist eines der wesentlichen Be- 
standteile der Losung. Dabei kann sowohl ein Software- 

60 sicherheitsmodul 3b, als auch ein Hardwaresicherheits- 
modul 3a verwandt werden. Die maximale Sicherheit 
vor digitalen Angriffen kann nur durch ein Hardwaresi- 
cherheitsmodul 3a erreicht werden. 
Der Kundenrechner 1 oder Handlerrechner 7 ist mit 

65 einem Netz 13 oder fiber eine direkte Telefonleitung 
miteinander verbundea Insbesondere sollen hier inho- 
mogene Netze betrachtet werden, wie bspw. das Inter- 
net Direkt am Netz 13 (Internet) ist auch der Home- 
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bankingserver Kundenbank 4 bpf^pptional der Home- 
bankingserver HandJerbank Si^i^. .te der die 

ankommenden Daten in die id^^ci^bank EDV 5 bzw. 
Handlerbank EDV 10 leitet Die Kundenbank 6 muB 
eine Moglichkeit fur Online-Transaktion fiir den Kun- 
den bieten. Die Handlerbank 11 hingegen muB nicht 
onlinefahig sein. 

Ais ein Realisierungsbeispiel soli anhand des Hardwa- 
resicherheitsmoduls 3a die Funkdon der Sicherheit des 
Systems eriautert werden. Innerhalb des Hardwaresi- 
cherheitsmoduls 3a, wobei es sich um einen einzelnen 
Schaltkreis oder um eine Chipkarte handeln kann, sind 
nachfolgende wesentiichen funktionellen Eiemente un- 
tergebracht, die in verschiedenen technischen Formen 
realisiert werden kdnnen (als Microcode, als fest ver- 
drahtete Schaltung oder als programmierbare Struktur 
usw.), Jedes Hardwaresicherheitsmodul 3a kann eine 
einmalige Nummer beherbergen oder andere selekti- 
vierende Kriterien erhaiten. 

Das Sicherheitsprotokoll mit Algorithmen 16 beinhal- 
tet die Algorithmen zur Ver- und Entschiusselung. 
Bspw. kdnnen sowohl symmetrisch als auch asymme- 
trisch Algorithmen verwandt werden. Wesentliche pro- 
tokollspezifische Funktionen werden ebenfalis in dieser 
Einheit abgewickelt (Schlussellange einstellen usw,). 

In der Schiusselfeldverwaltung 17 wird der Grund- 
stein fur eine sicher Kommunikation rait der Kunden- 
bank 61 Handlerbank 1 1 gelegt wobei hier verschieden 
Funktionen ausgefiihrt werden konnen. Die im folgen- 
den beschriebene Funktlon stellt nur ein Beispiel dar 
und soli die technische Machbarkeit aufzeigen. Das er- 
wiinschte Ergebnis kann jedoch technisch auch auf an- 
dere Weise erzeugt werden. 

Beim Ausgeben der einzelnen Hardwaresicherheits- 
module 3a, befinden sich Initalschliisselfelder in der 
Schiusselfeldverwaltung 17. Fiir jedes Hardwaresicher- 
heitsmodul 3a ist ein anderes SchlOsselfeld festgelegt 
Diese Initialschliisselfelder sind der Kundenbank 
6/Handlerbank 11 oder einer dritten Organisation be- 
kannt Bei dem ersten Kontakt wird das Initialschlussel- 
feld durch das kunden- und bankspezifische SchlOssel- 
feld Sbk 18 ersetzt bzw. parallel dazu in den Chip gela- 
den. Damit kann eine sichere Kommxmikation zur Kun- 
denbank 6/Handlerbank 11 aufgebaut werden, in dem 
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Es gibt verschieden||f|^dglichkeiten, die Anforderun- 
gen an ein Homebair Jystem zu erfullen, hier soil nur 
ein Beispiel erlSutertwrfden. 

Alle aus dem Netz 13 ankommenden Daten werden 
uber den Firewall 22 auf Unversehrtheit, Authentizitat 
usw. gepruft Dies geschieht bspw. indem direkt auf die 
Netzwerkkarte zugegriffen wird und die Datenpakete 
direkt von der Hardware geiesen werden um anschlie- 
Send zu uberpriifen, ob diese Daten mit einem Sicher- 
heitsmodul 3 verschlQsselt wurden oder nicht. Im nach- 
sten Schritt wird uberpriift, ob es sich dabei um Sicher- 
heitsmodule 3 handelt, die in der dynamischen Server- 
feldschliisselverwaltung 25 gespeichert sind Nur wenn 
auch diese Priifung positiv abgelaufen ist, werden die 
Daten akzeptiert und an den Kommunikationsserver 26 
weitergeleitet, welcher den Datensatz entschlusselt und 
die Signatur 39 auf Giiltigkeit uberpriift In der dynami- 
schen Serverschlusselfeldverwaltung 25 werden die von 
diesem Homebankingserver Kundenbank 4 erzeugten 
20 verschiedenen Schliisselfelder Sbk 18 (der Subindex B 
kennzeichnet die einzelne betrachtete Kundenbank 6 
innerhalb der Menge aller Banken, der Subindex K 
kennzeichnet den einzelnen betrachteten Kunden 2 in- 
nerhalb der Menge aller Kunden 2) fiir alie Kunden 
25 gespeichert und bei Bedarf zur Verfugung gestellt Der 
Signaturserver 23 erzeugt die einzelnen notwendigen 
Schlussel fur die Kundenbank 6 und den Kunden 2 um 
die einzeken elektronischen Signaturen 39 zu erzeugen 
und zu prufen. Der Kommunikationsserver 24 ist fiir die 
gesamte Kommunikation zur Kundenbank EDV 6 bin 
zustandig und fur die eigentiiche Ver- und Entschitissel- 
ung der Datenstrome. Dabei emuliert der Kommunika- 
tionsserver 24 das benotigte Frotokoll fiir die Kunden- 
bank EDV 6 da es sich hierbei um Systeme handelt, die 
nur mit sehr hohen Kosten geandert werden konnen. 
Jede Transaktion und alle relevanten Prozesse werden 
von dem ProtokoUserver 26 mitgeschreiben und stehen 
so bei eventuell auftretenden Fehlern zur Oberpriifung 
bereit 

Um den einzeben an das System angeschlossenen 
Kunden 2/Handlern 8, eine einfache Moglichkeit zur 
Priifung der Echtheit der einzelnen Aktionen zu ge- 
wahrleisten, muB ein authentischer Kanal geschaffen 
werden um die Prufelemente Pb 31 zu ubertragen. In 



30 



35 



40 



jeder ankonmiende Transaktionsschliissel mit dem 45 dem beschriebenen Ausfiihrungsbeispiel, sind die Priif- 



Schiiisselfeld der Bank umgeschliisselt wird und erst 
dann im Hardwaresicherheitsmodul 3a mit Hilfe dieses 
umgeschiiisseiten Schliissels die Informationen ver- 
oder entschliisselt werden. Verschiedene Banken kon- 
nen Ihre Schliisselfelder in das Sicherheitsmodul 3 por- 
tieren, die in der Schliisselfeldverwaltung 17 gespeichert 
werden. 

In derselben Art und Weise kdnnen die SchlQsselfel- 
der fiir Signaturen in das Hardwaresicherheitsmodul 3a 
geladen werden. Diese Signaturfunktionen sind wichtig 
im Zusammenhang mit dem Eingabesicherheitsmodul 
20. Das Emgabesicherheitsmodul 20 garantiert fur die 
Richtigkeit der Eingabe sowie dafiir, daB von der Einga- 
be bis zum Sicherheitsmodul 3 kerne Manipulationen an 
den Daten erfolgen. Dies geschieht bspw. indem die 
Tastatur 21 direkt mit dem Eingabesicheningsmodul 20 
verbunden ist und so keine Manipulationen der Eingabe 
moglich sind 

Das Homebankingserversystem bildet die Verbin- 
dung von der spezifischen Bank EDV 5/10 zum Netz 13. 
Dabei kann das System verschiedensten Anforderungen 
gerecht werden. Vorrangig muB natUrlich die Sicherheit 
der spezitischen Bank EDV 5/10 gewahrleistet werden. 



elememe Pb 31 die Publik Keys der Banken. Diese Pu- 
blik Keys sind nicht geheim, sollten aber iiber einen 
authentischen Kanal fur den Handler 8 beschaffbar sein. 
Gleichzeitig kann jeder Kunde 2 einfach zum Handier 8 
50 werden, indem er sich am Priifelementepoolserver 12 
meldet und mit Hilfe des Handlerregistrier- und Verwal- 
tungsmoduls 30 anhand der Nunmier seines Sicherheits- 
moduls 3 identifiziert wird. Nach dem er als Handler 8 
zugelassen wurde wird in der dynamischen Schiussel- 
55 feldverwaltung 25 ein handlerspezifisches Schlusselfeld 
Sh 28 (der Subindex H kennzeichnet den einzelnen be- 
trachteten Handlers innerhalb der Menge aller Handler 
8) kreiert, um spater in sein Sicherheitsmodul 3 geladen 
zu werden. Wenn der Handler 8 spater eine Bestatigung 
60 fiir eine getatigte Aktion des Kunden 2 oder seiner Kun- 
denbank 6/Handlerbank 11 uberpriifen mochte, so muB 
er mit dem erhaltenen Schlusselfeld Sh 28 den Prufele- 
mentepoolserver 12 kontaktieren und er erhalt aus dem 
Priifelementepoll 29 das entsprechende Priifelement 
65 (2. B.: den Public Key der Bank) Pb 31 (der Subindex B 
steht fiir die betrachtete Kundenbank 6 aus der Menge 
aller Banken) mit dessen Hilfe er die Echtheit der Besta- 
tigung vom Kunden 2 uber den Zahlungsvolizug uber- 



Liite uben die selben 
igserversystem be- 



prufen kann. Alle anderen 
Funktionen aus, wie im Homi 
reits beschrieben. 

Der Aufbau eines gesicherten Kanals kann bspw. der- 
art ausgefiihrt werden, in dem im Homebankingserver- 5 
system ein Private Key/Public Key Schlusselpaar er- 
zeugt wird, welches spater zur Erzeugung von Signatu- 
ren 39 verwandt wird. Dabei muB jedoch der bank- und 
kundenspezifische Public Key dem spateren Partner 
uber einen authentischen Kanal zugefQhrt werden, da- 10 
mit dieser die Echtheit der Signatur 39 vor Ort priifen 
kann. Deshalb wird der Public Key fiber einen gesicher- 
ten Kanal an den Priifelementepoolserver 12 ubertra- 
gen und dort abgespeichert Im Priifelementepoolserver 
12 sind somit alle Public Keys der Kundenbanken 6 15 
zuordenbar abgespeichert 

Im nachfolgenden Ausfuhrungsbeispiel wird gezeigt, 
wie der Handler 8 registriert wird- Das erfolgt in der 
Weise, daB im Hardwaresicherheitsmodul 3a vorverein- 
barte Initialschlusselfelder existieren, welche dem Pruf- 20 
eiementepoolserver 12 oder der Handlerbank 11 be- 
kannt sind, mit dessen Hilfe der Handler 8 den ersten 
Kontakt zum Priifelementepoolserver 12 aufbauen 
kann, nachdem er erfolgreich als Handler 8 registriert 
wurde. 1st die erforderliche Prufung zur Zulassung als 25 
Handler 8 (wirtschaftliche Prufung, Zulassung ect) er- 
folgreich abgelaufen, wird uber diesen sicheren Kanal 
bspw. mittels Verschlusselung 32 uber das Netz 13 dem 
Handler 8 ein entsprechendes handlerspezifisches 
Schliisselfeid Sh 28 ubertragen, mit dessen Hilfe er in 30 
Zukunft auf das Priifelement (z. B. den Public Key) Pb 31 
einer im System teibehmenden Kundenbank6 uber den 
Priifelementepoolserver 12 sicher und authentisch zu- 
greifen kann. Als Anwendungsbeispiei fflr eine modifi- 
zierte Variante kann der Handler 8, falls seine Handler- 35 
bank 11 auch einen Homebankingserver Handlerbank 9 
besitzt, was nicht unbedingt zur Abwickiung des Ver- 
fahrens notwendig ist, die Berechtigung und das hand- 
lerspezifische Schliisselfeid Sh 28 von seiner Handler- 
bank 11 erhalten, indem die Handlerbank 11, mit Hilfe 40 
ihres Homebankingservers Handlerbank 9, Uber den 
selben Kanal, mit welchem die Prufelemente Pb 31 gesi- 
chert an den Priifelementepoolserver 12 iibertragen 
wurden, den Priifelementepoolserver 12 kontaktiert 
und das entsprechende handlerspezifische Schliisselfeid 45 
Sh 28 zur sicheren Kontaktausfnahme fiir den Handler 8 
bezieht und seinerseits dieses an den Handler 8 iiber den 
gesicherten Kanal zwischen Handler 8 und dem Home- 
bankingserver Handlerbank 9 fibertragt 

Als Anwendungsbeispiei kann der Kunde 2 im Inter- 50 
net uber WEB Pages das Angebot des Handlers 8 be- 
trachten und sich ein ihn interessierendes Produkt aus- 
suchen. Nach der Auswahl, wird zwischen dem Handler 
8 und dem Kunden 2 iiber ein beliebiges bestehendes 
Softwaresicherheitsprotokoll (bspw. SSL usw.) ein si- 55 
cherer Kanal aufgebaut, in dem ein vorausgefullter 
Oberweisungssatz Handler 34 mit Zahlungsinformatio- 
nen 35 und erweiterten Informationen 36 die spater in 
der Handlerbank EDV 10 fiir die Zuordnung der Ober- 
weisung eine vereinfachende Rolle spielen werden, eo 
iibertragen wird. 

Die Zahiungsanweisung des Kunden 2 an den Hand- 
ler 8 kann sehr einfach und sicher fiir den Kunden 2 
gestaltet werden, indem bspw. durch einen einfachen 
Mausklick das zu belastende Konto dem vom Handler 8 65 
ausgestellten Oberweisungssatz Handler 34 hinzuge- 
fugt wird und nur noch der Betrag iiber die Tastatur 21 
direkt in das Sicherheitsmodul 3 eingegeben werden 
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muB. Indem der Kuj^^ den Betrag erneut eingegeben 
hat ist sichergestell^^Pdie Oberweisung vom Kunden 
2 genehmigt wurdH^achdem die Oberweisung mit 
Empfanger und Adressat vollstandig vorliegt, kann die- 
se verschliisselt und signiert werden, um dann iiber den 
sicheren Kanal zwischen der Kundenbank 6 und dem 
Kunden 2 iibertragen zu werden. Im Homebankingser- 
ver Kundenbank 4 wird die Oberweisung nach der Ent- 
schliisselung und der Oberpriifung der Echtheit der 
Oberweisung entsprechend der Syntax der speziellen 
Kundenbank EDV 5 umgerechnet und optional erganzt 
an die Kundenbank EDV 5 ubertragen. In dieser kann 
anschlieBend entscheiden werden, ob der Kunde 2 uber 
den zu uberweisenden Betrag verfiigen kann. Optional 
kann diese Entscheidung auch in dem Homebankingser- 
ver Kundenbank 9 getrof fen werden, falls entsprechen- 
de Angaben iiber den Kunden 2 im System vorliegen 
Oder von der Kundenbank EDV 5 abgefragt werden 
konnea 

Nach der Oberweisung durch die Kundenbank EDV 5 
kann die bestehende Handlerbank EDV 10 die Ober- 
weisungssatze der Handlerbank 11 einlesen und in be- 
wahner Art und Weise in ihrem Verwaltungssystem 
nutzen. ^ 

Die Oberpriifung des Bestatigungssatzes 38 vom 
Handler 8 erfolgt in der Weise, indem der Handler 8 die 
Signatur 39 des Bestatigungssatzes 38 durch das Priif- 
element (Public Key) Pb 31 der Bank uberpruft Fur 
haufiger genutzte Institute (groBe Banken) wird er in 
der Kegel die Priifelemente (Public Keys) Pb 31 schon 
auf seinem Handlerrechner 7 haben. Damit braucht er 
nur dann Kontakt mit dem Priifelementepoolserver 12 
aufnehraen, wenn ein Kunde 8 von einer Kundenbank 6 
zahlt, deren Prufelement (Public Key) Pb 31 noch nicht 
beim Handler 8 gespeichert ist 

Das beschriebene Verfahren zur Integration von 
Kunden 2 und Handlern 8 innerhalb bestehender Zah- 
lungsstrukturen bei der Abwickiung des Zahlungsver- 
kehrs iiber Netze 13 ist nicht auf Banken beschrankt An 
die Stelle der Kundenbank 4 und/oder der Handlerbank 
11 konnen beiiebige Finanzdienstleister treten, mit de- 
nen ahnliche Prozesse im Zahlungsverkehr abgewickelt 
werden. 

Verwendete Abkiirzungen 

VISA Handelsname 

MASTERCARD Handelsname 

SET-ProtokoU secure-electronic-transaction-protocoD 

DIGICASH Handelsname 

RSA Revest-Sharmir-Adelman Verschlusselungsalgo- 

rithmus 

DEBIT Handelsname 
WWW-Pages world wide web pages 
SSL security-socet-layer 

Bezugszeichenliste 

1 Kundenrechner 

2 Kunde 

3 Sicherheitsmodul 

3a Hardwaresicherheitsmodul 
3b Softwaresicherheitsmodul 

4 Homebankingserver Kundenbank 

5 Kundenbank EDV 

6 Kundenbank 

7 Handlerrechner 

8 Handler 
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9 Homebankingserver Handler^ 
lOHandlerbankEDV 

11 Handlerbank 

12 Priif elementepoolserver 

13 Netz 5 

14 Nutzerschnittstelle 

15 Protokoliebcne 

16 Sicherheitsprotokoli mit Algorithmen 

17 Schlusselfeldverwaltung 

18 Sbk (bank-und kundenspezifisches Schlusselfeld) lo 

19 Signaturfeldverwaltung 

20 Eingabesicherheitsmodul 

21 Tastatur 

22 Firewall 

23 Signaturserver 15 

24 Kommunikationsserver 

25 Dynamische Serverschlusselfeldverwaltung 

26 Protokoliserver 

27 Schiusself eidgenerierung 

28 Sh (handlerspezifisches Schlusselfeld) 20 

29 Prfifelementepool 

30 Handlerregistrier- und Verwaltungsmodul 

31 PB(bankspezifisches Prufelement) 

32 Verschlusselung 

33 Ware Dienstleistung 25 

34 Obenveisungssatz Handler 

35 Zahlungsinformationen 

36 erweiterte Informationen 

37 Obenveisungssatz Kunde 

38 Bestatigungssatz 30 

39 Signatur 

Patentanspriiche 

1. Verfahren zur Integration von Kunden und 35 
Handlern innerhalb bestehender Zahlungsstruktu- 
ren bei der Abwicklung des Zahlungsverkehrs iiber 
Netze, indem die Kunden mittels ihres Kunden- 
rechners den Zahlungsverkehr iiber Netzwerke mit 
ihrer speziellen Bank EDV abwickeln, dadurch ge- 40 
keimzeichnet, daB ein Priifelementepoolserver 
(12) das bankspezifische Prufelement Pb (31) der 
Kundenbank (6) authentisch einem Handler (8) si- 
cher zur Verfiigung stellt, welcher dadurch die er- 
folgreiche Abwicklung des Zahlungsverkehrs zwi- 45 
schen der Kundenbank (6) und der Handlerbank 

(11) kontrollieren kann, ohne das der Handler (8) 
einen Kontakt zu Handlerbank (11) aufnehmen 
muB, indem der Prufelementepoolserver (12) im 
PrOfelementepool (29) die bankspezifischen Priif- 50 
elemente Pb (31) der Banken gespeichert und auf 
Anforderung uber einen sicheren Kanal dem Hand- 
ler (8) zur Verfiigung stellt, indem eine sichere Ver- 
bindung zwischen dem Priifelementepoolserver 

(12) und dem Handler (8) tiber ein Netz (13) reaii- 55 
siert wird, indem die Verbindung zwischen dem 
Kunden (2) und der Kundenbank (6) iiber ein Si- 
cherheitsmodul (3) und dem Homebankingserver 
Kundenbank (4) abgewickelt wird, wobei der Ho- 
mebankingserver Kundenbank (4) sowohl den Da- eo 
tenverkehr mit dem Priifelementepoolserver (12) 
als auch mit der bestehenden Kundenbank EDV (5) 
abgewickelt, ohne daB Andenmgen an der Kun- 
denbank EDV(5) vorgenommen werden miissea 

2. Verfahren zur Integration von Kunden und es 
Handlern innerhalb bestehender Zahlungsstruktu- 
ren bei der Abwicklung des Zahlungsverkehrs uber 
Netze nach Anspruch 1 dadurch gekennzeichnet, 



im 1. Verfahrens^lB/ 

jeder Homebankingserver Kundenbank (4) iiber ei- 
nen gesicherten Kanal (z. B. durch Verschlusselung 
32) zwischen dem Homebankingserver Kunden- 
bank (4) und dem Prufelementepoolserver (12) sein 
bankspezifisches Priifelement Pb (31) an den Priif- 
elementepoolserver (12) sendet, so daB von alien an 
das System angeschlossenen Kundenbanken (6) die 
bankspezifischen Priifelemente Pa (31) im Priifele- 
mentepool (29) des Priif elementepoolservers (12) 
authentisch verf ligbar sind, 
im 2. Verf ahrensschritt 

der Handler (8) sich beim Prufelementepoolserver 

(12) als Handler (8) registrieren laBi, und einen si- 
cheren Kanal etabliert und somit eine authentische 
Zugriffsberechtigung auf den Priifelementepool- 
server (12) mit dem Priifelementepool (29) erhalt, 
im 3. Verfahrensschritt 

der Kunde (2) mit dem Handler (8) iiber das Netz 

(13) Kontakt aufnimmt, sich eine Ware Dienstlei- 
stung (33) auswahlt und bestellt, indem als Antwort 
auf die Bestellung in einem zwischen dem Handler 
(8) und dem Kunden (2) vereinbarten sicheren Ka- 
nal vom Handler (8) einen Oberweisungssatz 
Handler (34) an den Kunden (2) iibertragen wird, 
wobei der Oberweisungssatz Handler (34) aus Zah- 
lungsinfoimationen (35) und erweiterten Informa- 
tionen (36), in weichem verwaltungs- und produkt- 
spezifische Anmerkungen stehen, besteht, 

im 4, Verfahrensschritt 

der Kunde (2) die Oberweisung an den Handler (8) 
vomimmt, indem er mit Hiif e seines Sicherheitsmo- 
duls (3) den Oberweisungssatz Handler (34) kom- 
plettiert, indem er einen Oberweisungssatz Kunde 
(37) erstellt, so daB eine vollstandige Oberweisung 
entsteht, diese iiber einen sicheren Kanal vom Kun- 
denrechner (1) iiber den Homebankingserver Kun- 
denbank (4) an die Kundenbank EDV (5) der Kun- 
denbank (6) iibertragt, wo die Oberweisung geneh- 
migt Oder abgelehnt wird, 
im 5. Verfahrensschritt 

nach erfolgreicher Oberweisung der Kundenbank 
(6) an die Handlerbank (11) iiber bestehende Zah- 
lungsstrukturen von der Kundenbank EDV (5) der 
eine Nachricht an den Homebankingserver Kun- 
denbank (4) ausgeht, der Homebankingserver Kun- 
denbank (4) einen Bestatigimgssatz (38) generiert 
und auf dem sicheren Kanal zwischen dem Kunden 
(2) und dem Homebankingserver (4) an den Kun- 
den (2) ubertragt, 
im 6. Verfahrensschritt 

der Kunde (2) den Bestatigungssatz (38) und iiber 
einen beliebig mit dem Handler (8) vereinbarten 
Kanal an den Handler (8) iibertragt, 
im 7. Verfahrensschritt 

der Handler (8) den Bestatigungssatz (38) auf seine 
Echtheit uberpriift und bei Echtheit die Ware 
Dienstleistung (33) an den Kunden (2) liefert, indem 
er den Bestatigungssatz (38) mit Hilfe des bankspe- 
zifischen Priifelementes Pb (31) iiberpriift, indem er 
eine sichere Verbindung zum Priifelementepool- 
server (12) herstellt und sich das authentische bank- 
spezifische Priifelement Pb (31) in den Handler- 
rechner (5) iibertragt, falls er das Priifelement Pb 
(31) nicht schon auf seinem Rechner besitzt, und bei 
erfolgreicher Oberpriifung die Ware Dienstlei- 
stung (33) freigibt, 
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im8.Verfahrensschritt 

wenn die Oberweisung ^Hpr Kundenbank (6) 
erfolgt ist, kann die HaSKank EDV (10) wie 

bisher die Oberweisungssatze von der Handler- 
bank (1 1) einlesen und in ihrem Verwaltungssystem 5 
nutzen. 

3. Verfahren zur Integration von Kunden und 
Handlern innerhalb bestehender Zahlungsstruktu- 
ren bei der Abwicklung des Zahlungsverkehrs uber 
Netze nach Anspruch 1 und Anspruch 2 dadurch 10 
gekennzeichnet, daB im 1. Verfahrensschritt zur 
Generierung des bank- und kundenspezifischen 
Schlusselfelder Sbk (18) und des bankspezifischen 
Prufelementes Pb (31) im Homebankingserver 
Kundenbank (4) ein Private Key/Public Key 15 
Schlusselpaar erzeugt wird, welches spater zur Er- 
zeugung von Signaturen (39) verwandt wird, indem 
der Public Key dem Prufelementepoolserver (12) 
uber einen authentischen Kanal zugefiihrt und zu- 
sammen mit den Public Keys anderer Kundenban- 20 
ken (6) zuordenbar im Prufelementepool (29) abge- 
speichert wird. 

4. Verfahren zur Integration von Kunden und 
Handlern innerhalb bestehender Zahlungsstruktu- 
ren bei der Abwicklung dem Zahlungsverkehrs 25 
uber Netze nach Anspruch 1 und Anspruch 2 da- 
durch gekennzeichnet, daB im 2. Verfahrensschritt 
der Handler (8) das handlerspezifische Schliissel- 
feld Sh (28), welches ihm den authentischen Zugriff 
auf den Prufelementepoolserver (12) erlaubt, uber 30 
seine Handlerbank (11) beantragt, indem dieses 
handlerspezifische Schliisselfeld Sh (28) vom Pruf- 
elementepoolserver (12) in einer spezifisch nur fur 
den Handler (8) lesbaren Form in den Homebank- 
ingserver Handlerbank (9) ubertragen und in die- 35 
sem, emeut verschliisselt, iiber den sicheren Kanal 
zwischen dem Handler (8) und dem Homebanking- 
server Handlerbank (9) der Handlerbank (11) uber- 
tragen wird. 

5. Verfahren zur Integration von Kunden und 40 
Handlern irmerhalb bestehender Zahlungsstniktu- 
ren bei der Abwicklung des Zahlungsverkehrs uber 
Netze nach Anspruch 1 und Anspruch 2 dadurch 
gekennzeichnet, daB im zweiten Verfahrenschritt, 
das handlerspezifische Schlusselfeld Sh (28) fur den 45 
authentischen Zugriff des Handlers (8) zum Pruf- 
elementepoolserver (12) uber einen sicheren Kanal 
zwischen dem Prufelementepoolserver (12) und 
dem Handler (8) ubermittelt wird, indem fiir den 
Erstkontakt ein im Sicherheitsmodul (3) des Hand- 50 
lers (8) vereinbartes spezielles Initialschlusselfeld 
als Defaultschlusselfeld verwendet wird, welches 
nach erfolgreicher Anmeidung als Handler (8) mit 
dem eigentlichen handlerspezifischen Schlasselfeld 
Sh (28) Qberschrieben werden kann. 55 

6. Verfahren zur Integration von Kunden und 
Handlern innerhalb bestehender Zahlungsstruktu- 
ren bei der Abwicklung des Zahlungsverkehrs uber 
Netze nach Anspruch 1 und Anspruch 2 dadurch 
gekennzeichnet, daB im 3. Verfahrensschritt der eo 
Kunde (2) im Netz iiber WWW Pages das Angebot 
des Handlers (8) betrachten und sich erne ihn inter- 
essierende Ware Dienstleistung (33) Online aussu- 
chen und bestellen kana 

7. Verfahren zur Integration von Kunden und 65 
Handlern innerhalb bestehender Zahlungsstruktu- 
ren bei der Abwicklung des Zahlungsverkehrs uber 
Netze nach Anspruch 1 und Anspruch 2 dadurch 
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gekennzeichne^^B im 3. Verfahrensschritt die 
Zahlungsinfori^^Bi (35) unterscheidliche zah- 
lungsrelevante nroinationen, also Angaben iiber 
Bankleitzahl, Bankinstitut, Kontonummer, Name, 
Betrag, Wahrung und sonstige Organisationsinfor- 
mationen enthalt 

8. Verfahren zur Integration von Kunden und 
Handlern innerhalb bestehender Zahlungsstruktu- 
ren bei der Abwicklung des Zahlungsverkehrs iiber 
Netze nach Anspruch 1 und Anspruch 2 dadurch 
gekennzeichnet, daB im 4. Verfahrensschritt der 
UberweisungsprozeB durch die Nutzerschnittstelle 
(14) softwaremaBig fiir den Kunden (2) sehr einfach 
und sicher gestaltet ist, indem durch einen einfa- 
chen Mausklick dem vom Handler (8) ausgestellten 
Oberweisungssatz Handler (34) das zu belastende 
Konto hinzugefugt werden kann und nur noch der 
Betrag iiber die Tastatur (21) direkt in das Sicher- 
heiumodul (3) eingegeben werden muB, wodurch 
sichergestellt ist, daB die Oberweisung vom Kun- 
den (2) genehmigt wurde, da er den Betrag erneut 
eingegeben hat 

9. Verfahren zur Integration von Kunden und 
Handlern innerhalb bestehender Zahlungsstruktu- 
ren bei der Abwicklung des Zahlungsverkehrs iiber 
Netze nach Anspruch 1 und Anspruch 2 dadurch 
gekennzeichnet, daB im 4. Verfahrensschritt die 
Entscheidung iiber die Genehmigung/Ablehnung 
der Oberweisung direkt im Homebankingserver 
Kundenbank (4) getroffen wird, indem entspre- 
chende Angaben uber den Kunden (2) im System 
vorliegen oder von der Kundenbank EDV (5) abge- 
fragt werden konnen. 

10. Verfahren zur Integration von Kunden und 
Handlern innerhalb bestehender Zahlungsstruktu- 

ren bei der Abwicklung des Zahlungsverkehrs iiber 
Netze nach Anspruch 1 und Anspruch 2 dadurch 
gekennzeichnet, daB an die Stelle von der Kunden- 
bank (4) und/oder der Handlerbank (11) beliebige 
Finanzdienstleister treten konnen, mit denen ahnli- 
che Prozesse im Zahlungsverkehr abgewickelt 
werden. 

1 1. Anordnung zur Abwicklung von kostengunsti- 
gen Zahlungen auf digitalen Netzen dadurch ge- 
kennzeichnet, daB im Ausfuhrungsbeispiel ein Inte- 
grationssystem aus dem Kundenrechner (1) mit ei- 
nem Sicherheitsmodul (3), welches als Hardwaresi- 
cherheitsmodul (3a) oder Softwaresicherheitsmo- 
dul (3b) ausgefiihrt ist, aus einem Homebankingser- 
ver Kundenbank (4), einer Kundenbank EDV (5), 
dem Handlerrechner (7) mit dem Sicherheitsmodul 
(3) optional aus einem Homebankingserver Hand- 
lerbank (9), der Handlerbank EDV (10) und einem 
Prufelementepoolserver (12) besteht, wobei dieser 
von dem Handlerrechner (7), dem Homebanking- 
server Kundenbank (4) und optional dem Home- 
bankingserver Handlerbank (9) uber ein Netz (13) 
erreichbar ist 

12. Anordnung zur Abwicklung von kostengiinsti- 
gen Zahlungen auf digitalen Netzen nach Anspruch 
11 dadurch gekennzeichnet, daB das Sicherheits- 
modul (3) ein spezielles Hardwaresicherheitsmodul 
(3a) mit selektivierenden Kriterien ist, bestehend 
aus einem Sicberheitsprotokoll mit Algorithmen 
(16), einer Schliisselfeldverwaltung (17), dem ein 
bank- und kundenspezifisches Schlusselfeld Sbk 
(18) nach der Initialisierung zugeordnet ist, einer 
Signaturfeldverwaltung (19), sowie aus einem Ein- 
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gabesicherungsmodui (20),Ufcit derTastatur(21) 
in Wirkverbindung treten l^Mvodurch der Infor- 
mationsfluB von der Tastier (21) bis zur Ver- 
schliisselung (32) in einer geschlossenen Umgebung 
reaiisiertwird 5 
13. Anordnung zur Abwicklung von kostengunsti- 
gen Zahlungen auf digitalen Netzen nach Anspruch 
11 dadurch gekennzeichnet, daB der PrQfelemente- 
poolserver (12) aus dem Firewall (22), dem Kom- 
munikationsserver (24), der dynamischen Server- lo 
schlusselfeldverwaltung (25) mit der Schlusseifeld- 
generierung (27) den handlerspezifischen Schlussel 
Sh (28) dem Protokollserver (26), dem Prufelemen- 
tepool (29) und einem Handlerregistrier- und Ver- 
waltungsmodul (30) besteht, indem der Firewall 15 
(22) mit dem Kommunikationsserver (24) verbun- 
den ist und Qber das Netz (13) Daten austauscht, 
daB der Kommunikationsserver (24) mit der dyna- 
mischen Serverschiusselfeldverwaltung (25) mit der 
Schiasselfeldgenerierung (27) sowie mit dem Hand- 20 
lerregistrier- und Verwaltungsmodul (30) verbun- 
den ist und der Protokollserver (26) alle Datenstro- 
me uber den Kommunikationsserver (24) protokoi- 
liert 
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